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Mutual Authentication Protocol for HTTP: Cryptographic Algorithms 
Based on the Key Agreement Mechanism 3 (KAM3) 

Abstract 
This document specifies cryptographic algorithms for use with the 
Mutual user authentication method for the Hypertext Transfer Protocol 
(HTTP). 

Status of This Memo 
This document is not an Internet Standards Track specification; it is 
published for examination, experimental implementation, and 


evaluation. 


This document defines an Experimental Protocol for the Internet 
community. This document is a product of the Internet Engineering 


Task Force (IETF). It represents the consensus of the IETF 
community. It has received public review and has been approved for 
publication by the Internet Engineering Steering Group (IESG). Not 


all documents approved by the IESG are a candidate for any level of 
Internet Standard; see Section 2 of RFC 7841. 


Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc8121. 
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1. Introduction 


This document specifies algorithms for use with the Mutual 
authentication protocol for the Hypertext Transfer Protocol (HTTP) 
[RFC8120] (hereafter referred to as the "core specification"). The 
algorithms are based on augmented password-based authenticated key 
exchange (augmented PAKE) techniques. In particular, it uses one of 
three key exchange algorithms defined in ISO 11770-4 ("Information 
technology - Security techniques - Key management - Part 4: 
Mechanisms based on weak secrets") [ISO.11770-4.2006] as its basis. 
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To briefly summarize, the Mutual authentication protocol exchanges 
four values -- K_cl, K_sl, VK_c, and VK_s -- to perform authenticated 
key exchanges, using the password-derived secret pi and its 
"augmented version" J(pi). This document defines the set of 
functions K_cl, K_sl, and J for a specific algorithm family. 


Please note that from the point of view of literature related to 
cryptography, the original functionality of augmented PAKE is 
separated into the functions K_cl and K_sl as defined in this 
document, and the functions VK_c and VK_s, which are defined in 
Section 12.2 of [RFC8120] as "default functions". For the purpose of 
security analysis, please also refer to these functions. 


1.1. Terminology 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 
"OPTIONAL" in this document are to be interpreted as described in 
[RFC2119]. 


The term "natural numbers" refers to non-negative integers (including 
zero) throughout this document. 


This document treats both the input (domain) and the output 
(codomain) of hash functions as octet strings. When a natural-number 
output of hash function H is required, it will be notated, for 
example, as INT(H(s)). 


2. Cryptographic Overview (Non-normative) 


The cryptographic primitive used in this algorithm specification is 
based on a variant of augmented PAKE called "APKAS-AMP" (augmented 
password-authenticated key agreement scheme, version AMP), proposed 
by T. Kwon and originally submitted to [IEEE-1363.2_2008]. The 
general flow of the successful exchange is shown below for 
informative purposes only. The multiplicative notations are used for 
group operators, and all modulus operations for finite groups (mod q 
and mod r) are omitted. 
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C: S_cl = random 
C: K_cl = g%(S_cl1) 


----- ID, K_cl -----> 
C: t_l = H1(K_c1l) S: t_l = H1(K_cl) 
S: fetch J = g*pi by ID 
S: S_sl = random 
S: K_sl = (J * K_cl1%(t_1))%*(S_s1) 
<----- Kisii sea > 
C: t_2 = H2(K_cl, K_s1) S: t_2 = H2(K_cl, K_s1) 
C: z = K_s1*((S_cl + t_2) / (S_cl * t_1 + pi)) 
S: z’ = (K_cl * g*%(t_2))%*(S_s1) 
(assumption at this point: z = z’ if authentication succeeded) 
C: VK_c = H4(K_cl, K_sl, 2) S: VK_c’ = H4(K_cl, K_sl, 2’) 
{SaaS VRO sSSanScS 
S: assert (VK_c = VK_c’) 
C: VK_s’ = H3(K_cl, K_sl, 2) S: VK_s = H3(K_cl, K_sl, 2’) 
Kasse VRS SSS 


C: assert (VK_s = VK_s’) 


Note that the concrete (binary) message formats (mapping to HTTP 
messages), as well as the formal definitions of equations for the 
latter two messages, are defined in the core specification [RFC8120]. 
The formal definitions for values corresponding to the first two 
messages are defined in the following sections. 


3. Authentication Algorithms 


This document specifies one family of algorithms based on APKAS-—AMP, 
to be used with [RFC8120]. This family consists of four 
authentication algorithms, which differ only in their underlying 
mathematical groups and security parameters. These algorithms do not 
add any additional parameters. The tokens for these algorithms are 
as follows: 


o iso-kam3-d1-2048-sha256: for the 2048-bit discrete-logarithm 
setting with the SHA-256 hash function. 


o iso-kam3-d1-4096-sha512: for the 4096-bit discrete-logarithm 
setting with the SHA-512 hash function. 


o iso-kam3-ec-p256-sha256: for the 256-bit prime-field 
elliptic-curve setting with the SHA-256 hash function. 


o iso-kam3-ec-p521-sha512: for the 521-bit prime-field 
elliptic-curve setting with the SHA-512 hash function. 
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For discrete-logarithm settings, the underlying groups are the 
2048-bit and 4096-bit Modular Exponential (MODP) groups defined in 
[RFC3526]. See Appendix A for the exact specifications for the 
groups and associated parameters. Hash function H is SHA-256 for the 
2048-bit group and SHA-512 for the 4096-bit group, respectively, as 
defined in FIPS PUB 180-4 [FIPS.180-4.2015]. The hash iteration 
count niIterPi is 16384. The representation of the parameters "kci", 
"ks1l", "vkce", and "vks" is base64-fixed-number. 


For the elliptic-curve settings, the underlying groups are the 
elliptic curves over the prime fields P-256 and P-521, respectively, 
as specified in Appendix D.1.2 of the FIPS PUB 186-4 
[FIPS.186-4.2013] specification. Hash function H is SHA-256 for the 
P-256 curve and SHA-512 for the P-521 curve, respectively. Cofactors 
of these curves are 1. The hash iteration count nIterPi is 16384. 
The representation of the parameters "kcl1", "ks1", "vkc", and "vks" 
is hex-fixed-number. 


Note: This algorithm is based on the Key Agreement Mechanism 3 (KAM3) 
as defined in Section 6.3 of ISO/IEC 11770-4 [IS0O.11770-4.2006], with 
a few modifications/improvements. However, implementers should 
consider this document as normative, because several minor details of 
the algorithm have changed and major improvements have been made. 


3.1. Support Functions and Notations 


The algorithm definitions use the support functions and notations 
defined below. 


Decimal notations are used for integers in this specification by 
default. Integers in hexadecimal notations are prefixed with "0x". 


In this document, the octet(), OCTETS(), and INT() functions are used 
as defined in the core specification [RFC8120]. 


Note: The definition of OCTETS() is different from the function 
GE20S_x in the original ISO specification; GE20S_x takes the shortest 
representation without preceding zeros. 


All of the algorithms defined in this specification use the default 
functions defined in Section 12.2 of [RFC8120] for computing the 
values pi, VK_c, and VK_s. 
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3.2. Functions for Discrete-Logarithm Settings 


In this section, an equation (x / y mod z) denotes a natural number w 
less than z that satisfies (w * y) mod z = x mod z. 


For the discrete logarithm, we refer to some of the domain parameters 
by using the following symbols: 


o q: for "the prime" defining the MODP group. 
o g: for "the generator" associated with the group. 
o xr: for the order of the subgroup generated by g. 
The function J is defined as 

J(pi) = g*(pi) mod q 
The value of K_cl is derived as 

K_cl = g*%(S_cl) mod q 
where S_cl is a random integer within the range [1, r-1] and r is the 
size of the subgroup generated by g. In addition, S_cl MUST be 
larger than log(q)/log(g) (so that g*(S_cl) > q). 
The server MUST check the condition 1 < K_cl < q-1 upon reception. 
Let an intermediate value t_1 be 

t_1 = INT(H(octet(1) | OCTETS (K_cl))) 
The value of K_s1 is derived from J(pi) and K_cl as 

K_sl = (J(pi) * K_cl*%(t_1))*(S_s1) mod q 
where S_sl is a random number within the range [1, r-1]. The value 
of K_sl MUST satisfy 1 < K_s1 < q-l. If this condition is not held, 
the server MUST reject the exchange. The client MUST check this 
condition upon reception. 
Let an intermediate value t_2 be 

t_2 = INT(H(octet (2) | OCTETS(K_c1) | OCTETS (K_s1))) 


The value z on the client side is derived by the following equation: 


z = K_s1*((S_cl + t_2) / (S_cl * t_1 + pi) mod r) mod q 
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The value z on the server side is derived by the following equation: 
z= (K_cl * g*(t_2))*(S_s1) mod q 


(Note: The original ISO specification contained a message pair 
containing verification of value z along with the "transcript" of the 
protocol exchange. This functionality is contained in the functions 
VK_c and VK_s.) 


3.3. Functions for Elliptic—Curve Settings 


For the elliptic-curve settings, we refer to some of the domain 
parameters by the following symbols: 


o q: for the prime used to define the group. 


o G: for the point defined with the underlying group called 
"the generator". 


o h: for the cofactor of the group. 
o xr: for the order of the subgroup generated by G. 


The function P(p) converts a curve point p into an integer 
representing point p, by computing x * 2 + (y mod 2), where (x, y) 
are the coordinates of point p. P’(z) is the inverse of function P; 
that is, it converts an integer z to a point p that satisfies 

P(p) = z. If such p exists, it is uniquely defined. Otherwise, 

z does not represent a valid curve point. 


The operator "+" indicates the elliptic-curve group operation, and 
the operation [x] * p denotes an integer-multiplication of point p: 
it calculates p + p + ... (x times) ... + p. See the literature on 
elliptic-curve cryptography for the exact algorithms used for those 
functions (e.g., Section 3 of [RFC6090]; however, note that [RFC6090] 


uses different notations). O_E represents the infinity point. The 
equation (x / y mod z) denotes a natural number w less than z that 
satisfies (w * y) mod z = x mod z. 


The function J is defined as 


J(pi) = [pi] * G 
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The value of K_cl is derived as 


K_cl = P(K_cl’), where K_cl’ = [S_cl] * G 
where S_cl is a random number within the range [1, r-1]. The server 
MUST check that (1) the value of received K_cl represents a valid 
curve point and (2) [h] * K_cl’ is not equal to O_E. 


Let an intermediate integer t_1 be 
t_1 = INT(H(octet(1) | OCTETS (K_c1))) 
The value of K_s1 is derived from J(pi) and K_cl’ = P’ (K_cl) as 
K_sl = P([S_s1] * (J(pi) + [t_1] * K_cl’)) 
where S_sl is a random number within the range [1, r-1]. The value 
of K_sl MUST represent a valid curve point and satisfy 
[h] * P’ (K_s1) <> O_E. If this condition is not satisfied, the 
server MUST reject the exchange. The client MUST check this 
condition upon reception. 
Let an intermediate integer t_2 be 
t_2 = INT(H(octet (2) | OCTETS(K_cl) | OCTETS (K_s1))) 
The value z on the client side is derived by the following equation: 
z = P([(S_cl + t_2) / (S_cl * t_1 + pi) mod r] * P’ (K_s1)) 


The value z on the server side is derived by the following equation: 


z= P([S_s1l] * (P’ (K_cl) + [t_2] * G)) 
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4. IANA Considerations 


This document defines four new tokens that have been added to the 
"HTTP Mutual Authentication Algorithms" registry: 


4+------------------------- 4+—----------------------------- 4+—----------- + 
| Token | Description | Reference | 
+------------------------- 4+----------------------------- +----------- + 
iso-kam3-d1-2048-sha256 ISO-11770-4 KAM3, RFC 8121 
2048-bit DL 
| | | | 
| iso-kam3-d1-4096-sha512 | ISO-11770-4 KAM3, | RFC 8121 | 
| | 4096-bit DL | | 
| | | | 
| iso-kam3-ec-p256-sha256 | ISO-11770-4 KAM3, | RFC 8121 | 
| | 256-bit EC | | 
| iso-kam3-ec-p521-sha512 | ISO-11770-4 KAM3, | RFC 8121 | 
| | 521-bit EC | | 
4+------------------------- 4+----------------------------- +----------- + 
5. Security Considerations 


Please refer to the Security Considerations section of the core 
specification [RFC8120] for algorithm-independent considerations. 


5.1. General Implementation Considerations 


o During the exchange, the value VK_s, defined in [RFC8120], MUST 
only be sent when the server has received a correct (expected) 
value of VK_c. This is a cryptographic requirement, as stated in 
[ISO.11770-4.2006]. 


o All random numbers used in these algorithms MUST be 
cryptographically secure against forward and backward guessing 
attacks. 


o To prevent timing-based side-channel attacks, computation times of 
all numerical operations on discrete-logarithm group elements and 
elliptic-curve points MUST be normalized and made independent of 
the exact values. 
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Dees 


Cryptographic Assumptions and Considerations 


The notes in this subsection are for those who analyze the security 
of this algorithm and those who might want to make a derived work 
from this algorithm specification. 


(0) 


Oiwa, 


The treatment of an invalid K_s1 value in the exchange has been 
changed from the method defined in the original ISO specification, 
which specifies that the sender should retry with another random 
S_s1 value. We specify that the exchange must be rejected. This 
is due to an observation that this condition is less likely to 
result from a random error caused by an unlucky choice of S_s1 but 
is more likely the result of a systematic failure caused by an 
invalid J(pi) value (even implying possible denial-of-service 
attacks). 


The usual construction of authenticated key exchange algorithms 
consists of a key exchange phase and a key verification phase. To 
avoid security risks or vulnerabilities caused by mixing values 
from two or more key exchanges, the latter usually involves some 
kinds of exchange transactions to be verified. In the algorithms 
defined in this document, such verification steps are provided in 
the generalized definitions of VK_c and VK_s in [RFC8120]. If the 
algorithm defined above is used in other protocols, this aspect 
MUST be given careful consideration. 


The domain parameters chosen and specified in this document are 
based on a few assumptions. In the discrete-logarithm setting, 

q has to be a safe prime ([(q - 1) / 2] must also be prime), and 
r should be the largest possible value [(q - 1) / 2]. In the 
elliptic-curve setting, r has to be prime. Implementers defining 
a variation of this algorithm using a different domain parameter 
SHOULD be attentive to these conditions. 
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Appendix A. (Informative) Group Parameters for Algorithms Based on the 


Discrete Logarithm 


The MODP group used for the iso-kam3-d1-2048-sha256 algorithm is 
defined by the following parameters: 


The prime is 


q 


OxFFFFFFFF 


29024E08 
EF9519B3 
E485B576 
EE386BFB 
C2007CB8 
83655D23 
670C354E 
E39E772C 
DE2BCBF6 
15728E5A 


The generator is 


g 


2 


FFFFFFFF 
8A67CC74 
CD3A431B 
625E7EC6 
5A899FA5 
A163BF05 
DCA3AD96 
4ABC9804 
180E8603 
95581718 
8AACAA68 


C90FDAA2 
O020BBEA6 
302B0A6D 
F44C42E9 
AEQF2411 
98DA4836 
1C62F356 
F1746C08 
9B2783A2 
3995497C 
FFFFFFFF 


2168C234 
3B139B22 
F25F1437 
A637ED6B 
7C4B1FE6 
1C55D39A 
208552BB 
CA18217C 
ECO7A28F 
EA95 6AE5 
FFFFFFFF 


The size of the subgroup generated by g is 


r 


Oiwa, 


(q - 1) 


94812704 
F7CA8CD9 
F242DABB 
F71C35FD 
E1003E5C 
C1B2AE91 
B3861AA7 
F1ICF3B96 
EF15E5FB 
0AB9472D 
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/ 2 
Ox7FFFFFFE 


FFFFFFFF 
4533E63A 
E69D218D 
312F3F63 
AD44CFD2 
50B1DF82 
EE51D6CB 
255E4C02 
0C074301 
4RACOB8C 
45565534 


E487ED51 
0105DF53 
98158536 
7A262174 
D74F9208 
CC6D241B 
0E3179AB 
78BA3604 
CD93C1D1 
1CCAA4BE 
7FFFFFFF 


10B4611A 
1D89CD91 
F92F8A1B 
D31BF6B5 
BE258FF3 
OE2AE9CD 
1042A95D 
650C10BE 
7603D147 
754AB572 
FFFFFFFF 


T 


Experimental 


C4C6628B 
514A0879 
4FE1356D 
OBFF5CB6 
49286651 
69163FA8 
9ED52907 
32905E46 
B5SC55DF0 
15D22618 


62633145 
28A5043C 
A7FO9AB6 
85FFAE5B 
24943328 
348B1FD4 
CF6A9483 
19482F23 
DAE2AEF8 
8AE9130C 


80DC1CD1 
8E3404DD 
6D51C245 
F406B7ED 
ECE45B3D 
FD24CF5F 
7096966D 
2E36CE3B 
6F4C52C9 
98FA0510 


CO6EOE68 
C71A026E 
BOA8E122 
7A035BF6 
F6722D9E 
TE9267AF 
B84B4B36 
171B671D 
37A62964 
4C7D0288 
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The MODP group used for the iso-kam3-d1-4096-sha512 algorithm is 
defined by the following parameters: 


The prime is 


OxFFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 


q = 


29024E08 
EF 9519B3 
E485B576 
EE386BFB 
C2007CB8 
83655D23 
670C354E 
E39E772C 
DE2BCBF6 
15728E5A 
ECFB8504 
ABFSAE8C 
F1I2FFA06 
BBE11757 
43DB5BFC 
88719A10 
2583E9CA 
287C5947 
1F612970 
93B4EA98 
FFFFFFFF 


The generator is 


g 


Oiwa, 


et al. 


8A67CC74 
CD3A431B 
625E7EC6 
5A899FA5 
A163BF05 
DCA3AD96 
4ABC9804 
180E8603 
95581718 
8AAAC42D 
58DBEFOA 
DB0933D7 
D98A0864 
7A615D6C 
EOFD108E 


O20BBEA6 
302B0A6D 
F44C42E9 
AEQF2411 
98DA4836 
1C62F356 
F1746C08 
9B2783A2 
3995497C 
AD33170D 
8AEA7157 
1E8C94E0 
D8760273 
770988CO 
4B82D120 
99C32718 
DBBBC2DB 


3B139B22 
F25F1437 
A637ED6B 
7C4B1FE6 
1C55D39A 
208552BB 
CA18217C 
ECO7A28F 
EA956AE5 
04507433 
5D060C7D 
4A25619D 
3EC86A64 
BAD 946E2 
A9210801 
6AF4E23C 
O4DE8EF9 


514A0879 
4FE1356D 
OBFF5CB6 
49286651 
69163FA8 
9ED52907 
32905E46 
B5C55DF0 
15D22618 
A85521AB 
B3970F85 
CEE3D226 
521F2B18 
O8E24FA0 
1A723C12 
1A946834 
2E8EFC14 


99B2964F 
B81BDD76 
86FFB7DC 


A090C3A2 
2170481C 
90A6CO8F 


Experimental 


233BA186 
D0069127 
4DF435C9 


8E3404DD 
6D51C245 
F406B7ED 
ECE45B3D 
FD24CF5F 
7096966D 
2E36CE3B 
6F4C52C9 
98FA0510 
DF1CBA64 
A6E1E4C7 
1AD2EE6B 
177B200C 
74E5AB31 
A787E6D7 
B6150BDA 
1FBECAA6 
515BE7ED 
D5BO5AA9 
34063199 


[Page 14] 


RFC 8121 


HTTP Mutual Authentication: Algorithms 


The size of the subgroup generated by g is 


Te 


Oiwa, 


(q - 1) 


94812704 
F7CA8CD9 
F242DABB 
F71C35FD 
E1003E5C 
C1B2AE91 


/ 2 
Ox7FFFFFFE 


FFFFFFFF 
4533E63A 
E69D218D 
312F3F63 
AD44CFD2 
50B1DF82 
EE51D6CB 


E487ED51 
0105DF53 
98158536 
7A262174 
D74F9208 
CC6D241B 
0E3179AB 


B3861AA7 
FICF3B96 
EF15E5FB 
0AB9472D 
767DC282 
D5FAD746 
F897FD03 
5DFO8BAB 
A1LEDADFE 
C438CD08 
12C1F4E5 
143E2CA3 
8FBO094B8 
C9DAT754C 
FFFFFFFF 


et al. 


255E4C02 
00074301 
4RACOB8C 
45556216 
2CODF785 
6D8499EB 
6CC50432 
BD30AEB6 
707E8847 
5EDD2D93 
156A2674 
A735E02E 
67716BD7 
46C7EEEO 
FFFFFFFF 


78BA3604 
CD93C1D1 
1CCAA4BE 
D6998B86 
457538AB 


10B4611A 
1D89CD91 
F92F8A1B 
D31BF6B5 
BE258FF3 
OE2AE9CD 
1042A95D 
650C10BE 
7603D147 
754AB572 
82283D19 
AE83063E 


62633145 
28A5043C 
A7TFO9AB6 
85FFAE5B 
24943328 
348B1FD4 
CF 6A9483 
19482F23 
DAE2AEF8 
8AE9130C 
D42A90D5 
D9CB87C2 


8F464A70 
6C3B0139 
3B84C460 
25C16890 
4CE1938C 
6DDDE16D 
CCD94B27 
DCODEEBB 


2512BOCE 
9F 643532 
5D6CA371 
54908400 
357A711E 
826F477C 
D04861D1 
10B8240E 


C37FDBEE 


48536047 


Experimental 


E771E913 
290F958C 
047127D0 
8D391E09 
OD4A341A 
97477E0A 
119DDO0C3 
68034893 
A6FA1AE4 


April 2017 


CO6EOER68 
C71A026E 
BOA8E122 
7A035BF6 
F6722D9E 
7E9267AF 
B84B4B36 
171B671D 
37462964 
4C7D0288 
EF 8E5D32 
D370F263 
0D697735 
OBBD9006 
3A72D598 
53C3F36B 
5SBOA85ED 
OFDF6553 
28ADF3F6 
EAD82D54 
9A0318CC 
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Appendix B. (Informative) Derived Numerical Values 


April 2017 


This section provides several numerical values for implementing this 
protocol. These values are derived from the specifications provided 
in Section 3. The values shown in this section are for informative 


purposes only. 


t--- 55-555 === +--------- +--------- +- 
| | d1-2048 | al-4096 | 
t---- 5-5-5 == +--------- tenent Arae +- 
| Size of K_c1, | 2048 | 4096 | 

| etc. | | | 
| | | | 
| hSize, size of | 256 | 512 | 

| Gard.) | | | 
| Length of | 256 | 512 | 

| OCTETS (K_c1), | | | 

| etc. | | | 

| Length of kel, | 344* | 684* | 

ks1 param. 
values 

| | | | 
| Length of vkc, | 44* | 88* | 

| vks param. | | | 

| values | | | 

| Minimum | 2048 | 4096 

| allowed S_cl | | | 
e - 5-5-5 +--------- +--------- +- 


(The numbers marked with an "*" do not 
quotation marks.) 


Oiwa, et al. Experimental 


Jean tae Sel eel jail gi ts pe + gues ee Seed eit eggs snl eh ree oe +- 
ec-p256 | ec-p521 | 
iaie eek + seat Sant alah a e "Fh mh +- 
257 |522 | 

| | 

| | 
256 | 512 | 

| | 
33 | 66 

| | 

| | 

| | 
66 | 132 | 

| | 
64 | 128 

| | 

| | 
so iii | 

| | 
S +---------+ 


include any enclosing 


a + 
| 

saat + 
(bits) | 
| 

| 

(bits) | 
| 

(octets) | 
| 

| 

| 

(octets) | 
| 

(octets) | 
| 

| 

mornes Enn + 
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